Auto merge of #5314 - matklad:need-more-time, r=alexcrichton
Try to measure all time it takes to compile code
As @killercup noticed on IRC, no-op build by Cargo takes as much as 300 ms (on stable, beta and nightly), which seems unreasonable. However, Cargo wrongly reports ` Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs`, and this might be the reason why we haven't noticed this before.
So let's try to measure time slightly better:
```
~/projects/rustraytracer master*
λ time cargo +stable build
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
cargo +stable build 0.16s user 0.02s system 94% cpu 0.195 total
~/projects/rustraytracer master*
λ time $c build # Cargo with this patch applied
Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
$c build 0.30s user 0.02s system 96% cpu 0.330 total
```
Auto merge of #5307 - alexcrichton:another-fix, r=matklad
Fix another issue of poisoning too eagerly
This commit extends the fix in #5288 by moving the logic added farther up in the
loop over package dependencies. This means that we won't recursively look at
optional/dev path dependencies which aren't members of the workspace. This
should fix the new issue that came up in #5257
Alex Crichton [Fri, 6 Apr 2018 19:35:37 +0000 (12:35 -0700)]
Fix another issue of poisoning too eagerly
This commit extends the fix in #5288 by moving the logic added farther up in the
loop over package dependencies. This means that we won't recursively look at
optional/dev path dependencies which aren't members of the workspace. This
should fix the new issue that came up in #5257
Auto merge of #5302 - Eh2406:MoreRc, r=alexcrichton
use more Rc in the part of resolver that gets cloned a lot 2
This is the same idea as https://github.com/rust-lang/cargo/pull/5118, I was looking at a profile and noted that ~5% of our time was sent dropping `HashMap<PackageId, HashSet<InternedString>>`. A quick rg and I found the culprit, we are cloning the set of features for every new `Context`. With some Rc we are now just cloning for each time we insert.
To benchmark I commented out line https://github.com/rust-lang/cargo/blob/b9aa315158fe4d8d63672a49200401922ef7385d/src/cargo/core/resolver/mod.rs#L453
the smallest change to get https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286 not to solve instantly.
Before 17000000 ticks, 90s, 188.889 ticks/ms
After 17000000 ticks, 73s, 232.877 ticks/ms
Auto merge of #5280 - klausi:clippy-191-trvials, r=matklad
chore(clippy): Simplify minor stuff found by clippy
Executed clippy 0.0.191, fixed the trivial stuff.
Filed https://github.com/rust-lang-nursery/rust-clippy/issues/2615 for all the format_err!() false positives.
Auto merge of #5293 - Eh2406:InternMoreStrings, r=alexcrichton
Intern more strings
As pointed out in https://github.com/rust-lang/cargo/pull/5270#issuecomment-378372147, that clean up adds the mildly expensive `InternedString::new` to the hot path in the resolver.
The process of this PR is:
1. Find a `InternedString::new` in the hot path.
2. replace the argument of type `&str` that is passed along to `InternedString::new` with the type `InternedString`
3. add an `InternedString::new` to the callers until it type checked.
4. Repeat from step 1.
This stop if:
- It was traced back to something that was already an `InternedString`
- It was traced back to a `.to_string()` call
- It was in a persistent object creation
cc:
- @djc this is building on your work, I don't want to get in your way.
- @alexcrichton is this making things clearer and do you want to see a performance check?
Auto merge of #5270 - djc:feature-requirements, r=Eh2406
Introduce FeatureValue type to represent features table values
This is the next step towards #1286 (after #5258). The goal here is to have a central place in the code where feature strings are interpreted as (a) a feature, (b) a dependency or (c) a dependency/feature combo, and anchor that interpretation in the type system as an enum.
I've spent quite a bit of effort avoiding extra string allocations, complicating the code a bit; notice in particular the use of `Cow<str>` in `FeatureValue` variants, and the slight workaround in `Context::resolve_features()` and `build_requirements()`. I hope this is all okay.
Auto merge of #5288 - alexcrichton:another-fix, r=matklad
Less aggressively poison sources on builds
Discovered in #5257 the changes in #5215 were slightly too aggressively
poisoning sources to require updates, thinking that a manifest changed when it
actually hadn't.
Non-workspace-member path dependencies with optional/dev-dependencies
don't show up in the lock file, so the previous logic would recognize this and
think that the dependency missing from the lock file was just added and would
require a registry update.
The fix in this commit effectively just skips all of these dependencies in
non-workspace members. This means that this will be slightly buggy if an
optional dependency that's activated is added, but that's hopefully something we
can tackle later.
Alex Crichton [Tue, 3 Apr 2018 18:42:44 +0000 (11:42 -0700)]
Less aggressively poison sources on builds
Discovered in #5257 the changes in #5215 were slightly too aggressively
poisoning sources to require updates, thinking that a manifest changed when it
actually hadn't.
Non-workspace-member path dependencies with optional/dev-dependencies
don't show up in the lock file, so the previous logic would recognize this and
think that the dependency missing from the lock file was just added and would
require a registry update.
The fix in this commit effectively just skips all of these dependencies in
non-workspace members. This means that this will be slightly buggy if an
optional dependency that's activated is added, but that's hopefully something we
can tackle later.
Auto merge of #5203 - matklad:out-dir, r=alexcrichton
cargo build --out-dir
This is intended to fix https://github.com/rust-lang/cargo/issues/4875. Very much work in progress, just to figure out how exactly `--out-dir` should work :)
The path of least resistance for implementing `out-dir` would be to just link everything from `target/debug` to the `out-dir`. However, the problem with this approach is that we link *too much* to the `target/debug`. For example, if you run `cargo build --bin foo`, you'll find not only the `foo` itself there, but also rlibs from the same workspace.
I think it's rather important not to copy extra stuff to out-dir, so it is implemented as a completely new parameter, which is threaded through various config structs and applies *only* to the top-level units (i.e, to the stuff user explicitly requested to compile on the command line).
I also plan to add platform specific tests here, to check that we get .pdb on windows and .dSYM on macs for various crate-types.
Because, in general, a single target may produce multiple files, `out-dir` has to be a directory, you can't directly specify the output *file*.
Note that artifacts are still generated to the `target` dir as well.
Also cc @nirbheek, I hope that this might be useful for Meson integration, because `--out-dir` should be more straightforward to use than `--message-format=json`.
The end result, for `cargo build --bin rustraytracer --out-dir out` on windows looks like this:
Auto merge of #5278 - alexcrichton:no-rustfmt-ci, r=alexcrichton
Remove rustfmt from Travis
As discussed at the recent work week this is probably a bit too zealous at this
time, so let's hold off on it until it's either more stable or we figure out a
better way to deal with changes in rustfmt.
For now though it'll hopefully be easy to continue running rustfmt every so
often!
Alex Crichton [Mon, 2 Apr 2018 15:48:53 +0000 (08:48 -0700)]
Remove rustfmt from Travis
As discussed at the recent work week this is probably a bit too zealous at this
time, so let's hold off on it until it's either more stable or we figure out a
better way to deal with changes in rustfmt.
For now though it'll hopefully be easy to continue running rustfmt every so
often!
bors [Sat, 31 Mar 2018 13:28:20 +0000 (13:28 +0000)]
Auto merge of #5235 - klausi:Z-flag-docs, r=matklad
docs(Z-flags): Add description for each -Z flag in cargo help
Fixes #5155
There might be a more elaborate way of adding descriptions to available options and generating help text automatically. For now I think some static text is a good start.
bors [Fri, 30 Mar 2018 03:07:39 +0000 (03:07 +0000)]
Auto merge of #5258 - djc:split-resolver, r=Eh2406
Split resolver module to make it more manageable
The `core::resolver` module is currently the largest in Cargo, at some 2000 lines. Here's an attempt at splitting it into more reasonable parts and reordering the code in it for better comprehensibility.
Splitting is done in three major steps:
* Move the `Resolve` type and its dependencies into a separate module (~220 lines)
* Move utility data types into a separate module (~400 lines)
* Move the `Context` type and its dependencies into a separate module (~400 lines)
This halves the size of the root module, which is then reordered to make it more readable.
(This is a yak-shaving expedition of sorts, in preparation for #1286.)
bors [Tue, 27 Mar 2018 18:14:32 +0000 (18:14 +0000)]
Auto merge of #5252 - matklad:new-context-new, r=alexcrichton
Supply units to the context at the point of creation
This slightly reshuffles `Context` creation. The main benefit is that we know the set of units when we do `Context::new`, so we could use it to precalculate more things.
bors [Tue, 27 Mar 2018 13:58:26 +0000 (13:58 +0000)]
Auto merge of #5249 - alexcrichton:run-rustc-less, r=matklad
Run `rustc` for information fewer times
Currently if you pass `--target` the same as rustc's host Cargo will run `rustc`
on extra time to learn information, but we only need to run it once to learn
such information!
Alex Crichton [Tue, 27 Mar 2018 11:55:23 +0000 (04:55 -0700)]
Run `rustc` for information fewer times
Currently if you pass `--target` the same as rustc's host Cargo will run `rustc`
on extra time to learn information, but we only need to run it once to learn
such information!
bors [Mon, 26 Mar 2018 13:00:26 +0000 (13:00 +0000)]
Auto merge of #5228 - phil-opp:target-spec, r=alexcrichton
Add support for absolute target.json paths
Builds upon https://github.com/rust-lang/rust/pull/49019 with the goal to provide a solution to https://github.com/rust-lang/cargo/issues/4905.
This PR does two things:
~~1. It appends a hash of the target path to the target folder name if a `*.json` path is passed as `--target`, like it's done in https://github.com/rust-lang/rust/pull/49019. This helps differentiating targets with the same JSON file name and avoids sysroot clashes in `xargo`.~~ See https://github.com/rust-lang/cargo/pull/5228#discussion_r176827531
2. It canonicalizes the passed target path (if it's a `*.json` path), so that the path stays valid when building dependencies and setting the `RUST_TARGET_PATH` environment variable is no longer necessary.
projects / cargo.git / log